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General 

1.1  Background 


Reference  Architectures  (RAs)  are  system-  or  aspect  specific  and  provide  a  level  of  detail  required 
to  describe  common  behavior  for  more  than  one  Target  Architecture  system. 

In  a  large  and  complex  system,  which  the  MNE5  technical  system  is,  there  is  a  need  for  a  Reference 
Architecture  which  can  define  and  govern  the  more  detailed  architectural  components.  Definition 
and  governance  includes  things  like  componentization,  i.e.  dividing  the  architecture  into  smaller 
parts  and  also  specification  of  which  standards  etc  shall  be  used. 

1.2  Scope 

This  Reference  Architecture  is  system-specific  for  the  MNE5  technical  system.  This  means  that  it 
describes  a  technical  system,  not  a  mission  system  or  an  aspect. 

The  focus  is  on  functional  views,  not  deployment  views.  This  means  that  the  RA  will  describe  what 
functionality  shall  exist,  but  not  how  it  is  to  be  deployed  in  the  experiments.  However,  the  RA 
defines  an  example  model,  based  on  one  experiment  in  MNE5,  for  how  operational  views  are  to  be 
described. 

The  reason  for  not  specifying  all  deployment  views  is  that  these  will  look  very  different  depending 
on  what  type  of  experiment  is  currently  ongoing.  How  systems  are  deployed  in  the  various  MNE5 
experiments  is  to  be  described  in  the  “mission”  pillar  of  the  architectural  framework  [1]. 

1 .3  Short  description  of  the  “System  in  focus”  or  “Aspect  in  focus” 

The  MNE5  technical  system  aims  at  supporting  concept  development  and  experimentation  in  the 
realm  of  Comprehensive  Approach  (CA).  MNE5  is  a  series  of  experiments  running  from  2007 
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through  2008.  These  experiments  have  a  wide  range  in  their  set  up  and  goals  which  mean  that  the 
technical  system  needed  to  support  these  experiments  also  will  vary. 

Different  types  of  technical  applications  are  needed  in  the  experiments.  To  structure  these 
applications,  a  model  has  been  created  with  the  following  layers  of  functionality: 

Community  of  Interest  (COI)  Services 

Applications  aimed  at  specific  and  limited  user  communities.  These  have  few  or  no  interactions 
with  other  applications. 

Experiment 

Services  needed  to  support  the  experiment,  such  as  analysis  functions  and  scenario. 

Common  Services 

Applications  which  have  two  or  more  users.  I.e.  are  re-usable  components  which  have  the  potential 
of  being  available  in  most  experiments. 

Core  Services 

A  core  set  of  applications  which  are  needed  to  be  able  to  perfonn  an  experiment.  This  includes  user 
directories,  web  portal  and  collaboration  applications  etc. 

Core  Data  model 

A  data  model  which  contains  the  core  data  definitions  used  by  the  COMMON  and  CORE  services. 

Infrastructure  &  Network  Services 

The  base  computing  infrastructure,  including  operating  systems  etc.  as  well  as  network  and  network 
services  used  to  enable  communication  between  the  experiment  sites. 


Figure  1  shows  a  graphical  representation  of  what  is  contained  in  these  layers. 
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Figure  1  Architecture  layers  diagram 

1.4  Architecture  structure  and  related  documents 

1.4.1  Related  documents 

[1]  MNE5  Architecture  Description  Framework  1.0 

[2] 

1.5  References 

[3] 

[4] 

1.6  Abbreviations 

MNE5  -  Multi  National  Experiment  number  5 
CA  -  Comprehensive  Approach 
RA  -  Reference  Architecture 
TA  -  Target  Architecture 
OA  -  Overarching  Architecture 
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2  DESCRIPTION 

2.1  Technical  System  description 

2.1.1  NSOV-1  Service  taxonomy 

The  purpose  of  the  Sendee  Taxonomy  subview  is  to  organize  knowledge  according  to  the  service 
perspective,  and  to  facilitate  harmonization  of  services  across  multiple  domains  (or  across  multiple 
architectures). 

The  services  in  MNE5  are  divided  into  areas  as  depicted  in  Figure  1  Architecture  layers  diagram. 
This  taxonomy  has  been  specifically  developed  for  MNE5,  but  is  strongly  influenced  by  how  other 
architectures,  both  civilian  and  military,  define  service  taxonomy. 

Noteworthy  is  that  the  Experiment  layer  of  the  architecture  exists.  This  layer  contains  experiment 
specific  services  which  are  not  found  in  systems  which  are  intended  for  use  in  live  operations. 

It  is  also  important  to  know  that  the  focus  of  the  MNE5  architecture  is  on  describing  the 
components  which  are  common  for  many  users  or  experiments,  not  those  components  which  are 
used  in  a  limited  scope.  The  results  are  that  the  COI  level  services  are  not  described  in  as  much 
detail  as  the  COMMON  or  CORE  (see  Figure  1  Architecture  layers  diagram). 

2.1.2  NSOV-2  Service  definitions 

The  purpose  of  the  Service  Definitions  subview  is  to  strictly  delineate  and  define  services  in  order 
to  understand  the  operational  domain  in  terms  of  services  supporting  operational  activities. 

2. 1.2.1  Experiment  Services 


Area 

Service 

Service  description 

Experiment 

Scenario 

■  Scenario  setup 

■  Where  to  put  scenario  data 

■  How  to  tag  scenario  data  (live  vs  MNE5  specific) 

■  How  to  share  scenario  data 

Stimulation 

■  Injects  (incidents  etc) 

■  Ground  truth 

■  Situational  picture 

Experiment 

control 

■  Experimentation  preparation  and  control 

Experiment 

analysis 

■  Linked  to  Analysis  support  in  Systems  Management 

■  Capture  events/information  within  the  system 

■  Central  storage  of  log  data  for  analysis 

2. 1.2. 2  COI  Services 


Area 

Service 

Service  description 

CIP 

■ 

CIME 

■ 

MN  LA  Strat 
Planning 

■ 

MNIOIE 

(InfoOps) 

■ 
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KS 

■ 

KD 

■ 

SHIFT 

■ 

EBAO 

Red/Green 

teaming 

■ 

Joint  Action 

■ 

Collaborative 

synch. 

■ 

■ 

Logistics 

■ 

Medical 

■ 

CBRN 

■ 

Security 

■ 

2. 1.2.3  COMMON  Services 


Area 

Service 

Service  description 

Assessment 

services 

Visualization  of 
assessment  results 

■  Map  presentation  (use  of  Situational  Picture) 

■  Presentation  of  statistics  from  metrics  and  analysis 

■  Where  you  are  on  the  timeline 

Modeling  & 
Simulation 

■  Data  model  and  interface  for  simulation 

■  Simulation  tool(s)  (which  may  be  used  in  COIs) 

■  Course  of  action  modeling  &  simulation  (operation/mission)  (related  to 
Planning  in  C2  box) 

■  Effects  Based  Planning  (EBP)  modeling  &  simulation 

■  Assess  impact  on  culture,  system  of  the  country  (Also  linked  to  KD) 

Metrics  analysis 

■  Measures  of  effects  and  actions  (MOE  and  MOP) 

■  Measures  of  culture,  system  of  country  (Also  linked  to  KD) 

Statistics 

■  Making  statistics  from  lower  level  commands 

■  Statistic  algorithms 

■  Statistics  about  for  example  refugee  camps,  demographics 

Incident/Event 
management 
(“business  events”) 

Routing,  grouping 
and  prioritization 
of  incidents 

■ 

Storage  of 
incidents/events 

■ 

Incident/events 
life  cycle  mgmt 

■ 

Incident  discovery 

■ 

GIS  services  (static 
information) 

Description 

■  Maps  (vector,  raster),  Geo  info  (road  &  infrastructure,  buildings, 
elevation) 

Maps 

■  vector,  raster 

Geo  info 

■  road  &  infrastructure,  buildings,  elevation  etc 

Planning/C2 

services 

Description 

■  Planning  (incl  course-of-action/CoA),  Execution 

■  Includes  both  military  and  Civilian  planning 

■ 

Planning 

■  Course-of-action/CoA 

■  Planning  of  resources,  actions  and  effects  (mapping) 

■  Security  arena 

■  Integration  between  military  and  civilian  planning  tools 

■  Standardized  interface  for  exchanging  plan  data  (no  standards  exist  at 
operational  level) 

■  Assessment  plan 

Execution 

■  Monitoring  of  course  of  actions 

■  Monitoring  of  resources,  actions  and  effects  (link  with  sync  matrix) 

■  Manage  resources  (priority,  mission  orders/advices,  reorganization 
orders/advices,  logistics  orders/advices,  etc) 
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■  Link  with  assessment  results  (inputs  and  result) 

Computer  based 
training 

Description 

■  On-line/Off  line,  Course  management  (schedules,  user  completion  list) 

Knowledge 

processing 

Description 

■  Data/text  mining,  visualization  of  knowledge  (data  clusters,  influence 
diagrams),  Taxonomies 

■  Links  to  KD,  Incident  mgmt,  C2,  Assessment 

■  Scope: 

■  Management  of  information  data  flow 

■  Organization  of  knowledge  requests 

■  Linked  to  Workflow  in  Portal 

Taxonomies 

■  For  resources,  incidents,  actions,  effects  (JC3IEDM  related  +  additional 
EBAO  terms) 

■  Relationships  between  the  above  (actual  relations  stored  in 

Synchronization  service) 

Data/text  mining 

■  Collect  data  from  Incidents, 

■  Links  to  data 

■  Related  to  Information  discovery  in  Core  services 

Management  of 
information  data 
flow 

■  Visualization  of  knowledge  processing  /flow 

Office  tools  & 
templates 

Templates  & 
forms 

■ 

Language 

translation 

■ 

Language 

dictionary 

■ 

Common  terms  of 

references 

(jargon) 

■ 

Situational  Picture 

Geo  analysis 

■  Line  of  sight  etc. 

(dynamic 

information) 

Visualization 

■  Geo  analysis,  visualization,  dynamic  “layers:  Area  of  interest  info 
“theater”  (ethnic  population,  cultural  info,  current  ops,  e.g  track),  weather 

Dynamic  “layers 

■  Area  of  interest  info  “theater” 

■  ethnic  population,  cultural  info 

■  Current  ops,  e.g.  tracks, 

■  Weather 

Synchronization 

Description 

■  Relations  between  effects,  actions,  resources 

Resources 

Description 

■  Military  ORBAT  (whats  in  the  field,  what  are  you  prepared  to  do, 
capabilities,  organization),  civilian  assets,  add/remove/change  resources 

2. 1.2. 4  CORE  Services 


Area 

Service 

Service  description 

Security 

Cross-domain 

guard 

■  Allows  filtered  data  flow  between  different  domains  of  different 
classifications 

■  Messages  (xml,  JMS,  content  level. . .) 

■  Meta  data  filtering,  who  can  initiate  services 

■  Web  browsing 

■  Collaboration  &  messaging 

■  Border  protection  /  firewalls  not  included  (network  specific) 

Authentication  & 
authorization 

■  Identity  management 

■  Authorization  management 

■  by  name  &  role(s) 

■  Certificates  &  tokens  (soft  &  hard) 

■  includes  certificate  authority  &  revocation 

■  Privilege  enforcement  for  access 
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■  Person  and  machine  audit  logging 

Data  level  signing 

■  Hashes 

■  Data  objects,  web  services,  messages 

■  Signature  verification 

Encryption 

■  Key  management 

■  Messages 

■  (not  network  level,  VPN) 

■  Streaming  level  ? 

■  Session  (example  -  AES) 

■  SSL 

Collaboration 

Audio,  video 

■  Multi-party 

and  messaging 

■  VOIP  PSTN 

■  Record  &  replay 

Presence 

■  User  and  role  presence 

Conferencing 

■  Point  to  point 

(whiteboard, 

■  Conference  /  group 

application 

■  One  to  many 

sharing. 

■  Many  to  many 

presentation) 

■  Scheduling  &  invitation 

■  Record  &  replay 

■  Integration  with  document  management 

E-mail,  instant 

■  Text  chat 

messages 

■  E-mail  with  attachments 

■  Internet  e-mail  capability 

■  Digital  signatures 

Document 

■  Metadata  tagging 

management 

■  Versioning 

■  Baselining 

Portals  and 

Discussion  forum 

■  Wiki 

workflows 

■  Blogs 

Calendar 

■  Group  &  individual 

Publishing 

■  Content  management 

■  Syndications  (RSS,  ATOM,  etc) 

Data  storage, 

Storage 

■  Archiving 

redundancy, 

management 

■  Back-up  &  recovery 

recovery 

File  storage 

■  Network  accessible 

■  Group,  personal 

Virtual  database 

■  Distributed  data  sources? 

■  Web  services? 

Discovery, 

Discovery 

■  Content  search 

mediation, 

■  Services 

orchestration 

■  Users,  organizations,  roles 

■  Metadata 

■  Registries  (and  their  management) 

■  User 

■  Service 

Mediation 

■  Message  queuing 

■  Message  transformation 

■  Routing 

■  Service  (requests,  data  distribution,  binding) 

■  ETL  (extract,  transport,  load)  ? 

■  B2B  (business  to  business)  support 

Replication  & 

■  Registries 

synchronization 

■  Databases,  data 

System 

Helpdesk 

■  Online  ticketing  integrated  into  portal  environment 

Management 

■  System  status  display 

■  Information  on  minimum  requirements  for  installing/running  software 

Service 

■  Distribution  and  installation  of  software,  including  patches 
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Deployment 

■  Software  repository  with  approved  versions 

■  Configuration  management 

■  Software  versioning 

■  Hardware  configuration 

■  Services  versioning 

Analysis  support 

■  Logging 

■  Collection  of  service  level  (performance)  metrics;  QoS 

■  Collection  of  capacity  measures  for  assessment 

System 

Supervision  and 
Control 

■  Monitoring  software,  hardware,  services,  networks 

■  Service  prioritization  &  allocation 

■  Security  monitoring  (IDS,  etc) 

■  Policies 

■  Operations  (action  (start,  stop,  recovery,  etc),  service  management) 

■  System  dashboard  (network  operations  center,  MNE5  environment) 

2.1 .2.5  Infrastructure  &  Network  Services 


Area 

Service 

Service  description 

Computing 

infrastructure 

Operating  systems 

■  Client  and  server  side  operating  systems  such  as  Windows,  Linux  etc. 

Web  Browser 

■  Web/HTTP  browsers  such  as  Internet  Explorer  and  Mozilla  Firefox 

Document, 
Presentation  & 
Calculation  editor 

■  Office  tools  such  as  Microsoft  Word,  Powerpoint  and  Excel. 

Network 

DNS 

■  Domain  Name  System  servers  and  schema 

NTP 

■  Network  Time  Protocol 

VoIP 

■  Voice  over  IP  system  for  tech  support 

Network 

Management 

■  Network  Monitoring  using  SNMP 

2.1.3  NSV-1  Systems  Interface  Descriptions 

The  purpose  of  the  System  Interface  Description  is  to  illustrate  which  systems  collaborate  in  which 
way  to  support  the  operational  domain ’s  information  and  information  exchange  needs  as  defined  in 
the  Operational  View;  most  notably  in  NOV-2. 

NSV-1  links  together  the  Operational  View  and  the  System  View  by  depicting  which  systems  are 
resident  at  which  system  nodes.  Systems  nodes  may  in  reality  be  operational  nodes,  and  such 
duality  is  permissible. 

The  chapter  contains  references  to  Business  Process  Modeling  diagrams  which  is  the  closest  we  get 
to  an  Operational  View  in  the  architecture.  These  diagrams  describe  the  concepts  of  MNE5,  the 
activities  performed  in  these  concepts,  how  they  relate  to  each  other  and  how  they  relate  to 
technical  systems. 

To  support  the  execution  of  the  business  processes,  technical  systems  have  been  produced.  These 
are  described  in  chapter  2. 1.3.2  Deployable  Systems. 

This  Reference  Architecture  does  not  describe  which  technical  systems  are  resident  at  which  system 
nodes  for  each  and  every  experiment  in  MNE5,  but  an  example  deployment  model,  for  the  MNE5 
Enabling  Capabilities  experiment  (ENCAP08)  is  described.  Detailed  descriptions  of  which  systems 
are  deployed  in  which  system  nodes  for  all  experiments  can  be  found  in  the  Experiment  Design 
Documents  (EDD)  of  MNE5. 
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2. 1.3.1  Business  Process  Modeling 

The  MNE5  process  model,  depicted  in  Figure  2,  describes  the  MNE5  Comprehensive  Approach 
focus  areas.  Each  focus  area  is  described  with  organizational  entities  and  the  processes  these  entities 
performs.  Also  relationships  between  the  focus  area  processes  are  identified.  These  relationships 
often  indicate  a  need  for  information  sharing  using  information  technology. 


i . i 


riTTL  STL 


Figure  2  MNE5  process  model 
2. 1.3. 2  Deployable  Systems 

Deployable  systems  are  what  make  up  the  technology  in  MNE5,  they  provide  the  services  described 
in  chapter  2.1.2  NSOV-2  Service  definitions.  Figure  3  Deployable  components  diagram,  depicts  the 
different  systems  divided  into  the  different  layers  of  the  architecture  where  they  belong.  The  figure 
also  describes  which  products  are  used  to  realize  the  different  systems. 
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Figure  3  Deployable  components  diagram 


Experiment  layer  systems 

The  Survey  tool  system  provides  functionality  to  allow  the  experiment  audience  to  fill  out  surveys 
which  the  experiment  analysts  have  created.  This  is  vital  in  order  to  collect  the  overall  experience  of 
the  experiment  participants. 
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The  Analysis  store  system  stores  all  data  collected  during  the  experiments,  for  example  chat  logs,  e- 
mail  conversations  etc. 

COI  layer  system 

The  SHIFT  system  is  one  of  the  main  components  in  MNE5.  In  SHIFT,  government  and  non¬ 
government  actors  can  meet  and  share  information.  SHIFT  contains  several  subsystems  which 
correspond  to  parts  of  the  CORE  services  in  the  architecture,  for  example  a  Portal,  Collaboration 
system,  Document  Management,  Situational  Picture  and  Incident  management  systems.  It  also  has 
an  infrastructure  containing  security  and  mediation  services.  SHIFT  is  mainly  built  with 
commercial  products  from  IBM. 

The  Knowledge  Development  system  provides  aid  to  the  Knowledge  Development  analysts  so  that 
they  can  be  effective  in  understanding  complex  situations  and  theatre  systems.  The  KD  tool 
functionality  includes  a  web  crawling  system,  a  semantic  search  engine  (Infolution)  and  a  reasoning 
tool.  The  Knowledge  (i.e.  documents)  that  the  KD  team  produces  are  stored  in  a  Knowledge 
Database,  in  this  case  the  Alfresco  document  management  system  (see  Collaboration  services). 

COMMON  layer  systems 

The  Knowledge  Request  Management  system  provides  functionality  to  enter  and  manage 
Knowledge  Requests  which  makes  up  one  part  of  the  Knowledge  Support  concept. 

The  Situation  Picture  system  provides  a  view  of  the  current  situation  in  an  area,  displaying  units, 
events  and  areas  on  a  geographical  map. 

The  Planning  systems  aid  the  planners  in  a  Comprehensive  Approach  and  Effects  Based  Approach 
to  Operations  process.  In  MNE5  there  are  several  different  planning  tools  with  different  levels  of 
functionality  and  are  aimed  at  different  user  audiences. 

The  Planning  Information  Common  System  (PICS)  is  a  system  which  enables  the  planning  tools  to 
exchange  information  between  each  other,  thus  making  it  possible  to  have  the  same  information 
available  to  all  planners  in  a  Comprehensive  Approach. 

CORE  layer  systems 

In  the  Portal  and  Workflow  area  there  is  a  Portal  server  system  in  where  it  is  possible  to  deploy 
different  kinds  of  functionalities,  such  as  calendaring,  forums  and  publishing. 

In  the  Collaboration  area  there  are  several  systems.  The  Collaboration  system  provides  functionality 
for  users  to  communicate  with  each  other  through  chat,  voice  or  video  conference.  A  Document 
management  system  exist  which  allows  users  to  store  and  share  documents  as  well  as  handling 
versioning  of  the  documents.  The  E-mail  system  allows  users  to  send  and  retrieve  e-mail  messages. 

The  Security  area  provides  experiment  wide  systems  for  Authentication  (identity  control)  and 
Authorization  (access  control).  Also,  the  Cross  Domain  Guard  system  enables  infonnation 
exchange  over  domain  borders.  In  MNE5  information  is  transferred  between  the  SHIFT  and 
Coalition  (MCWAN)  domains. 

In  the  Discovery,  Orchestration  and  Mediation  area  the  Service  registry  system  enables  systems  to 
find  each  other,  like  a  telephone  book,  thus  eliminating  the  need  for  hard  coding  in  addresses.  The 
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User  Registry  and  Organization  registry  systems  provides  access  to  information  regarding  the 
organizational  structures  and  user  information  such  as  names,  addresses  etc. 

The  Search  engine  system  enables  the  users  to  discover  information  in  MNE5  and  this  system 
utilizes  the  Metadata  repository  as  one  source  of  data. 

To  enable  management  of  the  MNE5  technical  system  there  are  a  set  of  Monitoring,  Log  systems 
and  Action  systems  which  enables  the  technical  support  organization  to  collect  status  infonnation 
and  take  corrective  actions  if  needed.  Also,  a  Helpdesk  system  aids  the  support  organization  in 
handling  the  different  incidents  that  the  users  identify. 

Network  and  Computing  Infrastructure  layer  systems 

The  Client  platfonn  system  is  what  the  users  have  before  them  in  the  experiments.  This  is  built  with 
standard  off-the-shelf  products  and  provided  by  each  nation  where  users  are  located. 

To  create  the  networking  infrastructure,  a  time  synchronization  system  (NTP)  and  a  Domain  Name 
System  (DNS)  exist.  The  SIP  system  enables  the  technical  support  organization  to  communicate 
between  each  other  if  the  ordinary  collaboration  system  should  fail. 

2. 1.3. 3  Example  Deployment  Model  (ENCAP08) 

To  provide  an  insight  to  which  systems  are  deployed  where  an  example  deployment  model  is 
provided.  This  example  is  based  on  the  final  event  in  MNE5,  the  Enabling  Capabilites  08 
(ENCAP08)  where  a  large  portion  of  the  available  technology  was  demonstrated. 

The  overview  diagram  (Figure  4  ENCAP08  Deployment  overview)  depicts  systems  deployed  in 
three  different  zones,  the  Coalition  network  (MCWAN)  which  is  a  protected  VPN  network  used  for 
secure  infonnation  exchange,  a  Demilitarized  zone  (DMZ)  which  contains  the  systems  which  have 
access  to  the  internet,  like  SHIFT  and  the  third  zone  is  the  Internet  where  PCs  which  connect  to 
SHIFT  and  open  sources  are  located. 

In  ENCAP08  it  is  possible  to  exchange  information  between  the  DMZ  and  the  Coalition  network 
through  Cross  Domain  Guards.  The  guards  provide  secure  information  transfer  between  different 
security  zones. 

Within  the  Coalition  network  there  is  a  protection  on  a  network  level  using  ports  and  protocol 
protection,  similar  to  a  simple  firewall.  The  DMZ  is  protected  from  the  Internet  using  Firewalls. 
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Figure  4  ENCAP08  Deployment  overview 


2.1.4  NSV-2  Systems  Communications  Description 

The  goal  of  Systems  Communications  Description  is  to  provide  a  comprehensive  specification  of 
how  systems  are  connected,  what  interfaces  each  system  exposes  (ports),  the  hardware  interface 
used,  and  the  protocols  that  govern  transmission  of  data  across  the  interface. 

The  NSV-2  subviews  play  an  important  role  in  implementing  the  NATO  Network  Enabled 
Capability  strategy.  They  enable  acquisition  specialists  and  system  engineers  to  quickly  plan  and 
visualize  how  communications  between  systems  are  to  be  implemented.  When  NAF  is  used  as  an 
analytical  tool  for  existing  systems,  the  NSV-2  subviews  provide  a  detailed  way  to  document  the 
interfaces  exposed  by  those  systems. 

This  view  contains  an  overview  of  all  Service  Definition  documents,  or  other  sources  where 
information  on  the  specific  Services  can  be  found.  For  information  on  which  Systems  provide  or 
consume  these  Services,  see  section  2.1.5. 

This  section  only  describes  services  if  they  are  used  by  multiple  systems  for  information  exchange, 
there  are  other  services  and  standards  used  in  MNE5,  but  they  are  described  in  the  architectural 
document  of  each  system. 


2.1 .4.1  Service  Definitions  for  Experiment  Services 


Area 

Service  Definitions 

Experiment 

2.1 .4.2  Service  Definitions  for  COI  Services 


Area 


Service  Definitions 


UNCLASSIFIED  -  APPROVED  FOR  PUBLIC  RELEASE 


Chap  V  Sect  5  Information  Exchange  Ref  Architecture  for  MNE5  Tech  System.doc  15  of  21 


UNCLASSIFIED  -  APPROVED  FOR  PUBLIC  RELEASE 

Modified:  30  May  2007 


CIP 

CIME 

MN  IA  Strat  Planning 

MNIOIE  (InfoOps) 

KS 

KD 

SHIFT 

EBAO 

Logistics 

Medical 

CBRN 

Security 

2.1 .4.3  Service  Definitions  for  COMMON  Services 


Area 

Service  Definitions 

Assessment  services 

Incident/Event  management 
(“business  events”) 

GIS  services  (static 
information) 

Planning/C2  services 

Planning  Information  Common  Service  (PICS) 

Enables  exchange  of  planning  information  between  planning  tools.  Developed 
specifically  for  MNE5,  to  support  the  Effects  Base  Approach  to  Operations  (EBAO) 
process.  (Ref  to  doc) 

Computer  based  training 

Knowledge  processing 

Office  tools  &  templates 

Situational  Picture  (dynamic 
information) 

Synchronization 

Resources 

2.1 .4.4  Service  Definitions  for  CORE  Services 


Area 

Service  Definitions 

Security 

Authentication  Web  Service 

An  MNE5  specific  service  to  provide  external  authentication  possibilities.  Based  on  the  Swedish 
NBD  design  (FMLS2010).  (Ref  to  doc) 

Authorization  WS 

An  MNE5  specific  service  which  provides  external  authorization  management.  Based  on  the 
Swedish  NBD  design  (FMLS2010).  (|pf!to  l^) 

LDAP 

Standard  protocol  (RFC  XXXX)  for  authentication  and  authorization.  Primarily  used  for 
integration  of  commercial  products  that  cannot  be  adapted  to  the  custom  authentication  and 
authorization  services. 

Collaboration 
and  messaging 

XMPP 

Standard  protocol  (RFC  XXXX)  which  is  used  for  text  chat  and  presence  information. 

SIP 

Session  Initiation  Protocol  (RFC  XXXX)  used  for  initiating  voice  collaboration  sessions. 

SMTP 

Simple  Mail  Transfer  Protocol  (RFC  XXXX)  used  for  transfer  of  asynchronous  messages,  i.e.  E- 
mail. 

WebDav 
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Standard  for  retrieving  and  updating  documents  in  a  document  management  system.  (Ref  to 
standard) 

Portals  and 
workflows 

Data  storage, 

redundancy, 

recovery 

Discovery, 

mediation, 

orchestration 

UDDI 

Standard  (ref  to  standard)  for  enabling  systems  to  look  up  services  in  a  Service  Oriented 
Architecture. 

User  registry  Web  Service 

MNE5  specific  service  for  browsing  and  administering  a  user  directory.  Based  on  the  Swedish 
NBD  design  (FMLS2010).  (Ref  to  doc) 

Organization  registry  Web  Service 

MNE5  specific  service  for  browsing  and  administering  a  organization  directory.  Based  on  the 
Swedish  NBD  design  (FMLS20 10). 

LDAP 

Standard  protocol  (RFC  XXXX)  for  reading  user  and  organizational  data.  Primarily  used  for 
integration  of  commercial  products  that  cannot  be  adapted  to  the  custom  user  and  organization 
registry  services. 

Metadata  Web  Service 

MNE5  specific  service  for  adding  and  reading  metadata.  Enables  sharing  of  metadata  to  enable 
information  discovery  without  actually  sharing  the  data  itself.  Is  useful  when  having  large 
amounts  of  data  or  when  the  data  is  secret.  Based  on  the  Swedish  NBD  design  (FMLS2010).  (Ref 
to  doc) 

System 

Management 

WSDM 

Web  Services  Distributed  Management  (WSDM)  a  standard  for  enabling  Monitoring  and  ability 
to  perform  Actions  in  a  Web  Services  environment.  Insert  WSDM  SD  reference  here. 

File  Transfer  Protocol  (FTP)  Service: 

Standard  service  for  enabling  file  transfer.  No  MNE5  specific  document  is  created  for  this 
service.  For  information  on  the  FTP  Service,  go  to  httD://www. w3.org/Protocols/rfc959/. 

2.1 .4.5  Service  Definitions  for  Infrastructure  &  Network  Services 


Area 

Service  Definitions 

Computing  infrastructure 

Network 

Internet  Protocol 

Standard  for  enabling  exchange  of  data  packages  on  a  network.  (Ref  to  std) 

NTP 

Network  Time  Protocol,  standard  for  distributing  time  infonnation  to  enable 
synchronization  of  computerized  clocks.  (Ref  to  std) 

DNS 

Domain  Name  System,  standard  for  looking  up  hosts  on  a  network.  (Ref  to  std) 

2.1.5  NSV-3  System -to-System  Matrix  (S2  Matrix) 

The  Systems  to  Systems  Matrix  provides  detail  on  the  interface  characteristics  described  in  the 
NSV-1  subview  for  the  architecture,  arranged  in  matrix  form. 

An  NSV-3  product  allows  a  quick  overview  of  all  the  interface  characteristics  presented  in  multiple 
NSV-1  diagrams.  The  matrix  form  can  support  a  rapid  assessment  of potential  commonalities  and 
redundancies  (or,  if fault-tolerance  is  desired,  the  lack  of  redundancies). 

System/Service  Matrix,  (currently  in  Excel  spreadsheet.) 
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2.1.6  NSV-4  Systems  Functionality  Description 

The  primary  purpose  of  the  System  Functionality  Description  is  to: 

•  Describe  systems  that  are  outlined  in  NSV-1  in  more  detail,  both  in  terms  of  structure 
(functional  decomposition  of  systems)  and  behavior  (data  flows  between  system  components 
that  realize  certain  system  functions). 

•  Develop  a  clear  description  of  the  necessary  system  data  flows  between  systems  in 
accordance  with  NSV-1 1  data  definitions. 

•  Clearly  describe  the  allocation  of  system  functions  to  specific  systems,  system  components 
and/or  system  nodes  and  thus  clearly  delineate  lines  of  responsibility. 

•  Analyze  the  construction  of  NSV-1  systems  to  provide  a  basis  for  the  determination  of  the 
quality  requirements  for  systems  (refer  to  NSV-7)  in  support  of  the  Operational  View,  and 
making  decisions  about  streamlining,  combining  or  omitting  system  functionality. 

•  Provide  a  necessary  foundation  for  depicting  the  sequencing  and  timing  aspect  in  NSV-1 0. 

This  section  is  not  applicable  for  this  document,  much  of  the  information  can  be  found  in  chapter 
2. 1.3.2  Deployable  Systems.  For  even  more  details,  refer  to  the  system  description  documents 
which  are  provided  by  the  different  nations  which  provide  the  systems. 

2.1.7  NSV-6  Systems  Data  Exchange  Matrix 

The  Systems  Data  Exchange  Matrix  specifies  the  characteristics  of  the  system  data  exchanged 
between  systems.  This  product  focuses  on  automated  information  exchanges  (from  NOV-3).  Non- 
automated  information  exchanges,  such  as  verbal  orders,  are  captured  in  the  Operational  View 
only. 

System  data  exchanges  express  the  relationship  across  the  three  basic  architecture  entities  of  the 
System  View  (systems,  system  functions,  and  system  data  flows)  and  focus  on  the  specific  aspects  of 
the  system  data  flow  and  the  system  data  content. 

These  aspects  of  the  system  data  exchange  can  be  crucial  to  the  operational  mission  and  are 
critical  to  understanding  the  constraints  introduced  by  the  implementation. 

The  systems  data  exchange  matrix  has  not  been  developed  for  MNE5. 

2.1.8  NSV-7  System  quality  requirements  description 

One  of  the  primary  purposes  of  a  System  Quality  Requirements  Description  is  to  communicate 
which  quality  characteristics  are  considered  most  crucial  for  the  successful  achievement  of  the 
mission  goals  assigned  to  the  system.  These  particular  parameters  can  often  be  the  deciding  factors 
in  acquisition  and  deployment  decisions,  and  will  figure  strongly  in  systems  analyses  and 
simulations  done  to  support  the  acquisition  decision  processes  and  system  design  refinement. 

No  system  quality  requirements  description  has  been  developed  for  MNE5. 

2.1.9  NSV-8  Systems  evolution  description 

A  Systems  Evolution  Description,  when  linked  together  with  other  evolution  products  such  as  NCV- 
3  a,  NPV-1,  NSV-9  and  NTV-2,  provides  a  clear  definition  of  how  the  architecture  and  its  systems 
are  expected  to  evolve  over  time.  In  this  manner,  the  product  can  be  used  as  an  architecture 
evolution  project  plan  or  transition  plan. 

There  is  no  systems  evolution  development  description  for  MNE5.  This  evolution  is  likely  to 
happen  in  future  MNE  events. 
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2.1.10  NSV-9  Systems  technology  forecast 

The  purpose  of  the  Systems  Technology  Forecast  is  to  identify  relevant  emerging  technologies,  and 
to  ensure  that  the  architecture  benefits  from  it,  or  is  easily  adapted  to  it.  NSV-9  provides  a  summary 
of  emerging  technologies  that  impact  the  architecture  and  its  existing  planned  systems.  The  focus 
will  be  on  the  supporting  technologies  that  may  most  affect  the  capabilities  of  the  architecture  or  its 
systems. 


There  is  no  systems  technology  forecast  developed  for  MNE5. 

2.1.11  NSV-10  Systems  rules,  sequence  &  timing  description 

Many  of  the  critical  characteristics  of  an  architecture  are  only  discovered  when  an  architecture ’s 
dynamic  behaviors  are  defined  and  described.  These  dynamic  behaviors  concern  the  timing  and 
sequencing  of  events  that  capture  system  quality  characteristics  of  an  executing  system.  Behavior 
modeling  and  documentation  is  key  to  a  successful  architecture  description,  because  it  is  how  a 
future  system  behaves  that  is  crucial  in  many  situations.  Although  knowledge  of  the  functions  and 
interfaces  is  also  crucial,  knowing  whether,  for  example,  a  response  should  be  expected  after 
sending  message  X  to  node  Y  can  be  crucial  to  successful  overall  operations. 

Three  types  of  models  may  be  used  to  adequately  describe  the  dynamic  behaviour  and  performance 
characteristics  of  a  System  View.  These  three  models  are: 

•  Systems  Rules  Model  (NSV-lOa) 

•  Systems  State  Transition  Description  (NSV-lOb) 

•  Systems  Event-Trace  Description  (NSV-lOc) 

NSV-lOb  and  NSV-lOc  may  be  used  separately  or  together,  as  necessary,  to  describe  critical  timing 
and  sequencing  behavior  in  the  System  View.  Both  types  of  diagrams  are  used  by  a  wide  variety  of 
different  systems  methodologies. 

Both  NSV-lOb  and  NSV-lOc  describe  systems  responses  to  sequences  of  events. 

Events  may  also  be  referred  to  as  inputs,  transactions,  or  triggers.  When  an  event  occurs,  the  action 
to  be  taken  may  be  subject  to  a  rule  or  set  of  rules  as  described  in  NSV-lOa. 

2.1.12  NSV-11  System  data  model 

The  purpose  of  a  data  model  is  to  enable  analysis,  design  and  implementation  of  the  data 
presentation,  handling  and  storage  functionality  of  an  information  system. 

There  is  no  common  system  data  model  for  MNE5. 

2.1.13  NSV-12  System  communication  quality  requirements  description 

The  purpose  of  the  Systems  Communication  Quality  Requirements  description  (NSV-12)  is  to 
specify  specific  quality  requirements  applicable  to  communications  between  systems. 

Note  that  NSV-12  focuses  on  specific  categories  of  quality  requirements  for  systems 
communication.  This  focus  is  available  to  offer  separate  attention  to  certain  communication 
aspects,  other  than  already  specified  in  the  System  to  System  Port  Connectivity  description  (NSV- 
2b)  or  the  System  Connectivity  Clusters  subview  (NSV-2c).  At  the  moment  two  categories  are 
supported: 

•  NSV-12a:  Electromagnetic  Spectrum  Description  subview; 

•  NSV-12b:  Bandwidth  Description  subview. 

Analogous  to  NSV-7  offering  specification  of  quality  requirements  for  systems  defined  in  NSV-1  and 
NSV-4.  NSV-12  offers  specification  of  quality  requirements  for  system  communication  aspects 
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defined  in  NSV-2  (albeit  only  specific  categories  of  communications  related  quality  requirements 
that  are  not  already  addressed  in  NSV-2  itself). 

There  are  no  system  communication  quality  requirements  developed  for  MNE5. 

2.1.14  NSV-13  Service  provision 

The  purpose  of  the  Service  Provision  subview  (NSV-13)  is  to  illustrate  which  capability 
configurations  provide  which  services. 

The  NSV-13  subview  is  a  mapping  of  capability  configurations,  as  defined  in  NSV-1,  to  services,  as 
defined  in  NSOV-2. 

This  section  is  Not  Applicable  for  this  document.  Service  provisioning  is  to  be  described  in  the 
“mission”  pillar  of  the  architecture  description  framework. 

2.1.15  NTV-1  Technical  standards  profile 

The  Technical  Standards  Profile  (NTV-1)  provides  a  list  of  standards  guiding  and  constraining  the 
implementation  of  systems  as  defined  in  the  various  subviews  of  the  System  View.  The  NTV-1 
standards,  preferably,  are  NATO  standards,  as  this  will  allow  NATO  to  review  the  conformance  of 
system  implementation  with  the  policy  related  to  mandatory  interoperability  standards. 

There  is  no  technical  standards  profile  for  MNE5. 

2.1.16  NTV-2  Technical  standards  forecast 

The  purpose  of  the  Technical  Standards  Forecast  subview  (NTV-2)  is  to  identify  emerging,  obsolete 
and  fragile  standards,  and  to  assess  their  impact  on  the  architecture  and  its  constituent  elements.  A 
forecast  addressing  emerging  standards  will  give  insight  into  the  direction  that  the  project  will  go. 

There  is  no  technical  standard  forecast  for  MNE5. 

2.1.17  NTV-3  Standard  configurations 

The  purpose  of  the  Standard  Configurations  Description  (NTV-3)  is  to  describe  all  patterns, 
standard  configurations  and  best  practices  that  are  applied  to  or  emerge  from  the  architecture 
effort,  used  or  encountered  in  any  of  the  subviews  developed  in  the  architecture  effort. 

NTV-3  is  intended  to  capture  and  explicitly  describe  any  pattern,  configuration  or  best  practice  that 
is  of  value  to  the  ongoing  or  to  future  architecture  projects.  It  is  also  the  intention  of  this  subview  to 
provide  a  single  point  to  address  and  promote  the  use  of  patterns,  standard  configurations  and  best 
practices. 

No  standard  configurations  are  identified. 
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